[#ServerlessDays 2019]Zero Scale Abstraction in Knative Serving

加藤諒

2019.10.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

スライドが投稿され次第､追加と内容の修正を行う予定です｡

セッション概要

一言でいうと､Kubernetes(以降､k8s)をそのまま使うのは難しいので､実用的な方法で抽象化を行ってくれものです｡

Knativeは､k8sの上でサーバーレスをワークロードを動かす為のプラットフォームで､役割としてはCloudFoundaryやHerokuと近いと考えています｡
これによって､アプリケーションコードを書くだけで､実行し外部からリクエストを受ける事ができます｡

もし､Knativeに向かないところはk8sワークロードとして実行する事が可能なので､柔軟に構える事ができます｡

HTTPリクエスト駆動でスケーリングするプラットフォームです｡
k8sだと大量に必要なマニフェストが､Knativeなら比較して少ないマニフェストでサービスを立ち上げる事が可能になります｡Knativeが開発者の代わりにk8sのリソースを作成してくれる事によってこれは実現されています｡

バージョンに対してタグを付けることで､旧バージョンと新バージョンに対してリクエストを任意の割合で振り分けが可能になります｡これによって､本番にリリースする前に､開発者だけが実際に動作を確認する事が可能です｡

Zero Scaleするという事は､ユーザーからリクエストが来た際に､ワーカーが立ち上がるまでリクエストを保持する必要があります｡
また､アプリケーションがどれぐらいリクエストを処理できるかに応じて､スケーリングを行う必要があります｡

主要なコンポーネントとして以下があります｡

実際にZero Scaleする仕組みを説明します｡

後ほどスライドの図を追加します｡

AutoScaleの設定が細かくできる
- HTTPリクエストベースのスケールが可能
- スケールポリシーをある程度カスタマイズ可能
imagePullPolicy: Alwaysが不要
ローリングアップデートが安全
- k8sと比べて考慮点が少ない
- 上位のLBにワーカーが削除された事を伝えてるまでにラグがある
- Knativeならキューがリクエストを預かっているのでリクエストロストしない

Podに同梱できるコンテナは1つだけ
- istio-proxyやqueue-proxyは特別な対応を行って対処している
- プロポーサルは既に上がっている
ボリュームのマウントが制約がある
- 現時点ではプロポーサルは上がっていない
特定のノードでPodを立ち上げる事ができない
- アプリ開発者がノードを意識するのはサーバーレスの理念にそぐわない
スケールダウン時にDeploymentのレプリカ数を書き換えている
- どのPodが削除されるかはランダム(処理中のPodが狙われる可能性がある)
- 削除までの猶予時間は設定できるのでそれで対応する
- メトリクスで判断するプロポーサルが出ている